home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940149.txt < prev    next >
Internet Message Format  |  1994-11-13  |  15KB

  1. Date: Fri, 15 Jul 94 04:30:02 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #149
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Fri, 15 Jul 94       Volume 94 : Issue  149
  11.  
  12. Today's Topics:
  13.               800 mHz Trunked HT - To Person Interested
  14.                      Bridge vs. Repeater (2 msgs)
  15.                       Bridge vs. Repeater (fwd)
  16.                       DAMA v. Repeaters (4 msgs)
  17.                          PI/PI2 driver update
  18.  
  19. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  20. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  21. Problems you can't solve otherwise to brian@ucsd.edu.
  22.  
  23. Archives of past issues of the TCP-Group Digest are available
  24. (by FTP only) from UCSD.Edu in directory "mailarchives".
  25.  
  26. We trust that readers are intelligent enough to realize that all text
  27. herein consists of personal comments and does not represent the official
  28. policies or positions of any party.  Your mileage may vary.  So there.
  29. ----------------------------------------------------------------------
  30.  
  31. Date: Thu, 14 Jul 94 11:35:39 CDT
  32. From: route66@ddl.chi.il.us (System Administrator)
  33. Subject: 800 mHz Trunked HT - To Person Interested
  34. To: tcp-group@UCSD.EDU
  35.  
  36. I know this is off the topic..bt..
  37.  
  38. To the persn interested in my 800 mHz Trunked HT, and wanted them. I hav 
  39. lost your address so I'm unable to FedEx them to you. If you will email 
  40. me your address at route66@ddl.chi.il.us
  41.  
  42. Thanks,
  43. N9TOL De Greg
  44.  
  45. ------------------------------
  46.  
  47. Date: Thu, 14 Jul 1994 09:12:06 -0400
  48. From: goldstein@carafe.tay2.dec.com
  49. Subject: Bridge vs. Repeater
  50. To: tcp-group@UCSD.EDU
  51.  
  52. >Well, isn't there a bit more than that?  Even if two nearby users don't
  53. care about routing, a router can keep two local users from sucking up
  54. bandwidth... I'll share this with the group...
  55.  
  56. Routers and repeaters solve different problems.  When you maintain
  57. your car, do you change the oil or the check the tires?  Waddayamean
  58. both?  What kind of religious war are we having if we have two different
  59. correct answers?
  60.  
  61. A repeater -- operating in the physical layer -- is VITAL to solving the
  62. hidden transmitter problem.  I personally think DAMA's impractical for
  63. most ham use, for various reasons including the crappy radios we glue
  64. on to, but a repeater WILL get rid of HTS.  When you have Hidden
  65. Transmitter Syndrome, the actual channel capacity degrades to about
  66. 18-20% of bit rate, since it's effectively Aloha technology.  When you
  67. have a repeater and everyone hears everyone else when they're NOT
  68. transmitting, then you have CSMA and the channel capacity increases
  69. dramatically, MORE than doubling, though the actual efficiency depends
  70. on various timing factors.  When you have a repeater and everyone else
  71. is ALSO full duplex, then you have CSMA/CD and the channel capacity
  72. increases even more.  I've seen Ethernets run over 90% capacity, even
  73. though the theory says that you can't run over say 60% or so -- the
  74. theory assumes WORST CASE with everyone at maximum distance in a huge
  75. star.
  76.  
  77. So a repeater uses two frequencies but will get MORE bps/Hz than the
  78. crappy Aloha digis we have now.  It's insane that we don't use them
  79. on 2 meters more; haven't the old yakkers died off yet :-)?  The old
  80. first-come first-serve policy is enough to warrant giving the band
  81. over to commercial  users, almost, since it guarantees the obsoete old
  82. stuff will forever prevent more efficient newer users.
  83.  
  84. A router works at a higher layer, between users who do NOT have any
  85. physical layer connectivity (or at least that's it's main functiom).
  86. That's just not the same function as a repeater.  Now if the router
  87. were atop a mountain, it might choose not to pass along stuff that
  88. didn't need tocross the mountain.  But what does that solve?  The
  89. presence of one user's packets crossing the mountain will cause
  90. bits to be present on both sides, and local users will get clobbered
  91. anyway.  The mountaintop should probably have a repeater for the
  92. local users AND a router to go to OTHER mountaintops.
  93.    fred k1io
  94.  
  95. ------------------------------
  96.  
  97. Date: Fri, 15 Jul 1994 12:24:20 +1000
  98. From: makinc@hhcs.gov.au (Carl Makin)
  99. Subject: Bridge vs. Repeater
  100. To: tcp-group@ucsd.edu
  101.  
  102. At 10:57 AM 13/7/94 -0500, David Rush wrote:
  103.  
  104. > Because traffic between two stations on the left side of the mountain would
  105. > generate useless traffic (thru the regen) on the right side of the mountain.
  106. > (Sucking up bandwidth.)  A router could decide which packets need to cross
  107. > over the mountain, but otherwise stay quiet.
  108.  
  109. Whether you want to route or repeate depends on the traffic flow on the
  110. network and the topography of the surrounding terrain.
  111.  
  112. Canberra (Australia) is quite hilly and the BBSs are at the north and south
  113. ends of the city.  The biggest problem is hidden transmitters.  The terrain
  114. means even in the same "valley" many stations can not hear everyone else in
  115. the same "valley" and the majority of the traffic on frequency is going to
  116. or from the next "valley" anyway.  In this case a bit regen repeater solves
  117. a number of problems and as the traffic is mainly crossing between
  118. "valleys" then we don't lose bandwidth.  We also don't have enough local
  119. traffic to justify the expense of isolating the "valleys" and linking them
  120. via routers (yet).  We've chosen to make the entire ACT one "LAN" (for 4800
  121. baud traffic anyway).
  122.  
  123. > And when we say "bit regenerator", it's functionally equivalent to an
  124. > Ethernet repeater, aren't we?
  125.  
  126. Yes.
  127.  
  128. --
  129. Carl Makin (VK1KCM)          "Speaking for myself only!"
  130. makinc@hhcs.gov.au      'Work +61 6 289 8443'      Canberra, Australia
  131. 'The best book on programming for the layman is "Alice in Wonderland";
  132.  but that's because it's the best book on anything for the layman.'
  133.  
  134. ------------------------------
  135.  
  136. Date: Thu, 14 Jul 1994 09:05:19 -0500 (CDT)
  137. From: Kurt Freiberger <kurt@cs.tamu.edu>
  138. Subject: Bridge vs. Repeater (fwd)
  139. To: tcp-group@UCSD.EDU (TCP-Group Mailing List)
  140.  
  141. rush@dns.sprintcorp.com said:
  142. > Well, isn't there a bit more than that?  Even if two nearby users don't
  143. > care about routing, a router can keep two local users from sucking up
  144. > bandwidth... I'll share this with the group...
  145.  
  146. First of all, one needs to determine the topology of what one is trying to do.
  147. You have to define "local".  In most cases, "local" means LAN.  The audience
  148. is considered peers in one group, with one shared media.  It'd be nice if
  149. we had one channel for one path, but physics ain't with us.  A router inter-
  150. connects subnets.  A bridge interconnects LANs as peers within subnets.
  151.  
  152. > I said:
  153. > >> Yeah, presumably cross- or multi-banding would probably make the most
  154. > >> sense (easiest).  All of the stations in a "mutually hearable area" 
  155. > >> would share one freq on one band.  The stations in a different 
  156. > >> "mutually hearable area" (on the other side of the mountaintop 
  157. > >> router) would share a different freq on a different band.
  158. > Then Gerry said:
  159. > >So, why not use a wide area machine on 2 in-band frequencies, using the 
  160. > >regen? It's a "repeater" to the FM guys, simple to maintain, simple to 
  161. > >build, simple to install.  Find a good {tower/building top/mountain top} 
  162. > >and put it up to cover as much of the are as possible.  If you THEN have 
  163. > >an area that's not adequately covered, put up another regen in that area 
  164. > >on the reverse channel, or route over to that remote area.
  165. > Because traffic between two stations on the left side of the mountain would
  166. > generate useless traffic (thru the regen) on the right side of the mountain.
  167. > (Sucking up bandwidth.)  A router could decide which packets need to cross 
  168. > over the mountain, but otherwise stay quiet.
  169.  
  170. It depends on whether you need the other side of the mountain to be a
  171. different subnet.  The decision to use a single regenerator (repeater)
  172. on the top vs two regenerators with an interconnect is one of economics.
  173. Obviously, two radio sites with interconnects is more expensive.
  174. If you have two regenerators, then you can decide whether to route or
  175. bridge according to the LAN topology.  To subnet or not to subnet, that
  176. is the question?
  177.  
  178. > Assuming that nobody even cares about routing in this case, what I'm
  179. > really proposing is a bridge (to use Ethernet terminology) between
  180. > the two sides of the mountain, rather than bit regenerator.
  181. > And when we say "bit regenerator", it's functionally equivalent to an 
  182. > Ethernet repeater, aren't we?
  183.  
  184. You have it exactly.
  185.  
  186. I've been mulling over the design of a bridge for AX.25, and how that could 
  187. work in our environment.  There are some DEFINITE gotchas, especially with
  188. regard to bridging loops.  I didn't really want to deal with spanning-tree
  189. at all!!!!
  190.  
  191. 73/Kurt
  192. -- 
  193. # Kurt Freiberger, WB5BBW   Dept. of Computer Science, TAMU              #
  194. # Internet: kurt@cs.tamu.edu      |  "Even MY hypocrisy has its limits." #
  195. # AuralNet: 409/847-8607          |                                      #
  196. # AMPRNet: wb5bbw@wb5bbw.ampr.org |        - "Doc" Holliday, Tombstone   #
  197. # Disclaimer: Not EVEN an official document of Texas A&M University      #
  198.  
  199. ------------------------------
  200.  
  201. Date: Thu, 14 Jul 1994 11:50:09 -0500 (CDT)
  202. From: ssampson@sabea-oc.af.mil (Steve Sampson)
  203. Subject: DAMA v. Repeaters
  204. To: tcp-group@ucsd.edu
  205.  
  206. goldstein@carafe.tay2.dec.com writes:
  207. > I personally think DAMA's impractical for most ham use, for various reasons
  208. > including the crappy radios we glue on to, but a repeater WILL get rid
  209. > of HTS.
  210.  
  211. Well I think a crappy radio will not perform either DAMA or Repeater duty, so
  212. I guess I don't understand your logic.  Why DAMA won't succeed in most
  213. Western societies is because we are raised to always seek power in our sphere.
  214. That means every Ham will want to be the Master Node, and not submit to being
  215. a Slave.  Here in Oklahoma City we have more Nodes than users because that's
  216. how people are.  If you ask them if they want to create a network the answer
  217. is: NO!     They just want to beacon their Callsign and own a frequency.
  218.  
  219. Oops, I've drifted from technology to behavior again. . . sorry.
  220.  
  221. -- 
  222. Steve
  223.  
  224. ------------------------------
  225.  
  226. Date: Thu, 14 Jul 1994 14:20:11 -0400
  227. From: goldstein@carafe.tay2.dec.com
  228. Subject: DAMA v. Repeaters
  229. To: tcp-group@ucsd.edu
  230.  
  231. > I think a crappy radio will not perform either DAMA or Repeater duty, so
  232. I guess I don't understand your logic.  Why DAMA won't succeed in most
  233. Western societies is because we are raised to always seek power in our sphere.
  234. That means every Ham will want to be the Master Node, and not submit to being
  235. >a Slave.
  236.  
  237. Nope, that's not why I think DAMA won't cut it.
  238.  
  239. First off the average radio doesn't HAVE to do repeater duty; a CSMA
  240. (no /CD) arrangement is probably the happy medium;  tha'ts ONE repeater
  241. and ORDINARY HDX radios.
  242.  
  243. DAMA itself is based on polling, right?  So in DAMA, you need to make
  244. FAST polls to potential users.  Long Txdelay times make it fail, and
  245. that's the problem.  If there are 50 users on the freq. and only 3 are
  246. active, you avhe to waste time poling 47.  For a wireline tolkien ring
  247. that's no issue; they take microseconds.  But voice-oriented ham
  248. radios take many milliseconds to be polled.  Way way too many.
  249.  
  250. ALso, the protocols we use are not master/slave; or are they very
  251. happy about waiting long times for a round-robin poll to take place.
  252. Super-fast polling would fix that but I just don't see it.
  253.  
  254. Other than that, Mrs. Lincoln, how did you like the play?
  255.     fred k1io
  256.  
  257. ------------------------------
  258.  
  259. Date: Thu, 14 Jul 1994 13:55:45 -0500 (CDT)
  260. From: ssampson@sabea-oc.af.mil (Steve Sampson)
  261. Subject: DAMA v. Repeaters
  262. To: tcp-group@ucsd.edu
  263.  
  264. > DAMA itself is based on polling, right?
  265.  
  266. Yes.
  267.  
  268. > So in DAMA, you need to make FAST polls to potential users.  Long Txdelay
  269. > times make it fail, and that's the problem.
  270.  
  271. Well it would be a problem compared to NO txdelay true.
  272.  
  273. > If there are 50 users on the freq. and only 3 are active, you have to waste
  274. > time poling 47.
  275.  
  276. Well, as I understand it - When you are polled and respond with IDLE, the Node
  277. will begin backing off on your poll timing.  So the 3 active will get the
  278. channel while the 47 IDLE users will get more and more backoff.  Then if one
  279. more user switches from IDLE to ACTIVE they get back to high priority again.
  280. I guess this is akin to Prioritized Round Robin in Task scheduling.
  281. -- 
  282. Steve
  283.  
  284. ------------------------------
  285.  
  286. Date: Thu, 14 Jul 94 14:22 EDT
  287. From: nelson@crynwr.com (Russell Nelson)
  288. Subject: DAMA v. Repeaters
  289. To: tcp-group@ucsd.edu
  290.  
  291.    From: goldstein@carafe.tay2.dec.com
  292.    Date: Thu, 14 Jul 1994 14:20:11 -0400
  293.  
  294.    DAMA itself is based on polling, right?  So in DAMA, you need to make
  295.    FAST polls to potential users.  Long Txdelay times make it fail, and
  296.    that's the problem.  If there are 50 users on the freq. and only 3 are
  297.    active, you avhe to waste time poling 47.  For a wireline tolkien ring
  298.    that's no issue; they take microseconds.  But voice-oriented ham
  299.    radios take many milliseconds to be polled.  Way way too many.
  300.  
  301. But if only three are active, why waste time polling 47?  Why not make
  302. a poll priority list, doing an exponential (up to a point) fallback in
  303. priority.
  304.  
  305. Also, why should the hub be doing any transmitting?  It should just
  306. assign slot times for the users, assigning more slots to more active
  307. users.
  308.  
  309. Or is DAMA some sub-optimal scheme that someone is pushing as a
  310. universal solution?  I'm afraid I've got my "Answer for every question
  311. regardless of my ignorance" hat on.
  312.  
  313. -russ <nelson@crynwr.com>    http://www.crynwr.com/crynwr/nelson.html
  314. Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
  315. 11 Grant St.      | +1 315 268 1925 (9201 FAX)  | What art thou doing about it?
  316. Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.
  317.  
  318. ------------------------------
  319.  
  320. Date: Fri, 15 Jul 1994 00:00:22 -0400 (EDT)
  321. From: dp@pluto.va3dp (Dave Perry va3dp)
  322. Subject: PI/PI2 driver update
  323. To: tcp-group@ucsd.edu
  324.  
  325. A driver update is available which improves performance for the B port on
  326. PI and PI2 cards. Depending on the host machine, it should now be capable
  327. of 9600 baud (on 386 class machines). Also included is a bugfix that should
  328. eliminate rx overruns.
  329.  
  330. This update is for the NOS source code. The Linux driver update will follow.
  331. It is available for ftp from hydra.carleton.ca as:
  332.                                                                                 
  333. pub/hamradio/packet/tcpip/pi2/pi.c
  334.  
  335. Dave
  336. va3dp
  337.  
  338. ------------------------------
  339.  
  340. End of TCP-Group Digest V94 #149
  341. ******************************
  342.